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Abstract 


A "security incident" as defined in the "Internet Security Glossary", 
RFC 2828, is a security-relevant system event in which the system’s 
security policy is disobeyed or otherwise breached. The purpose of 
this document is to provide System Administrators with guidelines on 
the collection and archiving of evidence relevant to such a security 
incident. 


If evidence collection is done correctly, it is much more useful in 
apprehending the attacker, and stands a much greater chance of being 
admissible in the event of a prosecution. 
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1 Introduction 


A "security incident" as defined in [RFC2828] is a security-relevant 
system event in which the system’s security policy is disobeyed or 
otherwise breached. The purpose of this document is to provide 
System Administrators with guidelines on the collection and archiving 


of evidence relevant to such a security incident. It’s not our 
intention to insist that all System Administrators rigidly follow 
these guidelines every time they have a security incident. Rather, 


we want to provide guidance on what they should do if they elect to 
collect and protect information relating to an intrusion. 


Such collection represents a considerable effort on the part of the 
System Administrator. Great progress has been made in recent years 
to speed up the re-installation of the Operating System and to 
facilitate the reversion of a system to a ’known’ state, thus making 
the ’easy option’ even more attractive. Meanwhile little has been 
done to provide easy ways of archiving evidence (the difficult 
option). Further, increasing disk and memory capacities and the more 
widespread use of stealth and cover-your-tracks tactics by attackers 
have exacerbated the problem. 


If evidence collection is done correctly, it is much more useful in 
apprehending the attacker, and stands a much greater chance of being 
admissible in the event of a prosecution. 


You should use these guidelines as a basis for formulating your 
site’s evidence collection procedures, and should incorporate your 
site’s procedures into your Incident Handling documentation. The 
guidelines in this document may not be appropriate under all 
jurisdictions. Once you’ve formulated your site’s evidence 
collection procedures, you should have law enforcement for your 
jurisdiction confirm that they’re adequate. 


1.1 Conventions Used in this Document 
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 


and "MAY" in this document are to be interpreted as described in "Key 
words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 
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2 Guiding Principles during Evidence Collection 


- Adhere to your site’s Security Policy and engage the 
appropriate Incident Handling and Law Enforcement personnel. 


- Capture as accurate a picture of the system as possible. 


- Keep detailed notes. These should include dates and times. If 
possible generate an automatic transcript. (e.g., On Unix 
systems the ’script’ program can be used, however the output 
file it generates should not be to media that is part of the 
evidence). Notes and print-outs should be signed and dated. 


- Note the difference between the system clock and UTC. For each 
timestamp provided, indicate whether UTC or local time is used. 


- Be prepared to testify (perhaps years later) outlining all 


actions you took and at what times. Detailed notes will be 
vital. 
- Minimise changes to the data as you are collecting it. This is 


not limited to content changes; you should avoid updating file 
or directory access times. 


- Remove external avenues for change. 


- When confronted with a choice between collection and analysis 
you should do collection first and analysis later. 


- Though it hardly needs stating, your procedures should be 
implementable. As with any aspect of an incident response 
policy, procedures should be tested to ensure feasibility, 
particularly in a crisis. If possible procedures should be 
automated for reasons of speed and accuracy. Be methodical. 


- For each device, a methodical approach should be adopted which 
follows the guidelines laid down in your collection procedure. 
Speed will often be critical so where there are a number of 
devices requiring examination it may be appropriate to spread 
the work among your team to collect the evidence in parallel. 
However on a single given system collection should be done step 
by step. 


- Proceed from the volatile to the less volatile (see the Order 
of Volatility below). 


Brezinski & Killalea Best Current Practice [Page 3] 


RFC 3227 Evidence Collection and Archiving February 2002 


- You should make a bit-level copy of the system’s media. If you 
wish to do forensics analysis you should make a bit-level copy 
of your evidence copy for that purpose, as your analysis will 
almost certainly alter file access times. Avoid doing 
forensics on the evidence copy. 


2.1 Order of Volatility 
When collecting evidence you should proceed from the volatile to the 


less volatile. Here is an example order of volatility for a typical 
system. 


registers, cache 


- routing table, arp cache, process table, kernel statistics, 
memory 


- temporary file systems 
- disk 


- remote logging and monitoring data that is relevant to the 
system in question 


- physical configuration, network topology 
- archival media 
2.2 Things to avoid 
It’s all too easy to destroy evidence, however inadvertently. 

- Don’t shutdown until you’ve completed evidence collection. 
Much evidence may be lost and the attacker may have altered the 
startup/shutdown scripts/services to destroy evidence. 

- Don’t trust the programs on the system. Run your evidence 
gathering programs from appropriately protected media (see 


below). 


- Don’t run programs that modify the access time of all files on 
the system (e.g., ‘tar’ or ’xcopy’). 
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When removing external avenues for change note that simply 
disconnecting or filtering from the network may trigger 
"deadman switches" that detect when they’re off the net and 
wipe evidence. 


2.3 Privacy Considerations 


Respect the privacy rules and guidelines of your company and 
your legal jurisdiction. In particular, make sure no 
information collected along with the evidence you are searching 
for is available to anyone who would not normally have access 
to this information. This includes access to log files (which 
may reveal patterns of user behaviour) as well as personal data 
files. 


Do not intrude on people’s privacy without strong 
justification. In particular, do not collect information from 
areas you do not normally have reason to access (such as 
personal file stores) unless you have sufficient indication 
that there is a real incident. 


Make sure you have the backing of your company’s established 
procedures in taking the steps you do to collect evidence of an 
incident. 


2.4 Legal Considerations 


Computer evidence needs to be 


Admissible: It must conform to certain legal rules before it 
can be put before a court. 


Authentic: It must be possible to positively tie evidentiary 
material to the incident. 


Complete: It must tell the whole story and not just a 
particular perspective. 


Reliable: There must be nothing about how the evidence was 
collected and subsequently handled that casts doubt about its 
authenticity and veracity. 


Believable: It must be readily believable and understandable 
by a court. 
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3 The Collection Procedure 


Your collection procedures should be as detailed as possible. As is 
the case with your overall Incident Handling procedures, they should 
be unambiguous, and should minimise the amount of decision-making 
needed during the collection process. 


3.1 Transparency 


The methods used to collect evidence should be transparent and 
reproducible. You should be prepared to reproduce precisely the 
methods you used, and have those methods tested by independent 
experts. 


3.2 Collection Steps 


- Where is the evidence? List what systems were involved in the 
incident and from which evidence will be collected. 


- Establish what is likely to be relevant and admissible. When 
in doubt err on the side of collecting too much rather than not 
enough. 

- For each system, obtain the relevant order of volatility. 


- Remove external avenues for change. 


- Following the order of volatility, collect the evidence with 
tools as discussed in Section 5. 


- Record the extent of the system’s clock drift. 


- Question what else may be evidence as you work through the 
collection steps. 


- Document each step. 


- Don’t forget the people involved. Make notes of who was there 
and what were they doing, what they observed and how they 
reacted. 


Where feasible you should consider generating checksums and 
cryptographically signing the collected evidence, as this may make it 
easier to preserve a strong chain of evidence. In doing so you must 
not alter the evidence. 
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4 The Archiving Procedure 


Evidence must be strictly secured. In addition, the Chain of Custody 
needs to be clearly documented. 


4.1 Chain of Custody 


You should be able to clearly describe how the evidence was found, 
how it was handled and everything that happened to it. 


The following need to be documented 


- Where, when, and by whom was the evidence discovered and 
collected. 


- Where, when and by whom was the evidence handled or examined. 


- Who had custody of the evidence, during what period. How was 
it stored. 


- When the evidence changed custody, when and how did the 
transfer occur (include shipping numbers, etc.). 


4.2 Where and how to Archive 


If possible commonly used media (rather than some obscure storage 
media) should be used for archiving. 


Access to evidence should be extremely restricted, and should be 
clearly documented. It should be possible to detect unauthorised 
access. 

5 Tools you'll need 
You should have the programs you need to do evidence collection and 
forensics on read-only media (e.g., a CD). You should have prepared 
such a set of tools for each of the Operating Systems that you manage 
in advance of having to use it. 
Your set of tools should include the following: 


- a program for examining processes (e.g., 'ps’). 


- programs for examining system state (e.g., ’showrev’, 
‘ifconfig’, ‘netstat’, ‘’arp’). 


- a program for doing bit-to-bit copies (e.g., ’dd’, '’SafeBack’). 
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- programs for generating checksums and signatures (e.g., 
"shalsum’, a checksum-enabled ‘dd’, ’SafeBack’, ‘’pgp’). 


- programs for generating core images and for examining them 
(e.g., "’gcore’, gdb’). 


- scripts to automate evidence collection (e.g., The Coroner's 
Toolkit [FAR1999]). 


The programs in your set of tools should be statically linked, and 
should not require the use of any libraries other than those on the 
read-only media. Even then, since modern rootkits may be installed 
through loadable kernel modules, you should consider that your tools 
might not be giving you a full picture of the system. 


You should be prepared to testify to the authenticity and reliability 
of the tools that you use. 
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8 Security Considerations 


This entire document discuses security issues. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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